5.5 KB · ⇊ 2 parts · ⤓ Micron 5.5 KB · ⤓ HTML 8.5 KB

layout: Wide · Narrow · Centered

top

Connected Data Objects (CDO) is a free implementation of a Distributed Shared Model on top of the Eclipse Modeling Framework (EMF).

With CDO, programmers can easily enhance existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default, CDO provides for pluggable storage adapters that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side, CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the CDO protocol are imaginable as well.

• Model integration features

• User interface features

• Client side features

• Network protocol features

• Server side features

• DB store features

• External links

• EMF integration at model level (as opposed to the edit level)

• Support for generated models (just switch two .genmodel properties)

• Support for dynamic models (just load .ecore file and commit to repository)

• Support for legacy models (for compiled models without access to .genmodel)

• Support for the Ecore meta model and descendants

• Eclipse view for working with CDO sessions, transactions, views and resources

• Package Manager dialog per session

• Eclipse editor for working with resources and objects

• Multiple sessions to multiple repositories on multiple servers

• Multiple transactions per session

• Multiple read-only views per session

• Multiple audit views per session (an audit is a view that shows a consistent, historical version of a repository)

• Multiple resources per view (a view is always associated with its own EMF ResourceSet)

• Inter-resource proxy resolution

• Multiple root objects per resource

• Object state shared among all views of a session

• Object graph internally unconnected (unused parts of the graph can easily be reclaimed by the garbage collector)

• Only new and modified objects committed in a transaction

• Transactions can span multiple resources

• Demand loading of objects (resources are populated as they are navigated)

• Partial loading of collections (chunk size can be configured per session)

• Adaptable pre-fetching of objects (different intelligent usage analyzers are available)

• Asynchronous object invalidation (optional)

• Clean API to work with sessions, views, transactions and objects

• CDOResources are EObjects as well

• Objects carry meta information like id, state, version and life span

• Support for OSGi environments (headless, Eclipse RCP, ...)

• Support for standalone applications (non-OSGi)

• Net4j based binary application protocol

• Pluggable transport layer (shipped with NIO socket transport and JVM embedded transport)

• Pluggable fail over support

• Pluggable authentication (shipped with challenge/response negotiation)

• Multiple acceptors per server

• Pluggable storage adapters

• Multiple repositories per server

• Multiple models (packages) per repository

• Multiple resources (instance documents) per repository

• Expressive XML configuration file

• Configurable storage adapter per repository (see below)

• Configurable caching per repository

• Clean API to work with repositories, sessions, views, transactions and revisions

• Support for OSGi environments (usually headless)

• Support for standalone applications (non-OSGi)

• Supports all optional features of the CDO Server

• Pluggable SQL dialect adapters

• Includes support for Derby, HSQLDB, MySQL and Oracle (TBD)

• Pluggable mapping strategies

• Includes horizontal mapping strategy (one table per concrete class)

• Includes vertical mapping strategy (TBD, one table per class in hierarchy)

• Supports different mapping modes for collections

• CDO Homepage